1. Technical Field
The present invention relates generally to Web service-based access and other policy control.
2. Background of the Related Art
A Web service is a software system identified by a URI, whose public interface and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by the Web service definition, using XML-based messages conveyed by Internet protocols.
Typically, a Web service is described using a standard, formal XML notion, called its service description. A service description typically conforms to a machine-processable format such as the Web Services Description Language (or WSDL). WSDL describes the public interface to necessary to interact with the service, including message formats that detail the operations, transport protocols and location. The supported operations and messages are described abstractly and then bound to a concrete network protocol and message format. A client program connecting to a Web service reads the WSDL to determine what functions are available on the server. Computing entities running the Web service communicate with one another using XML-based messaging over a given transport protocol. Messages typically conform to the Simple Object Access Protocol (SOAP) and travel over HTTP (over the public Internet) or other reliable transport mechanisms (such as IBM® MQSeries® technologies and CORBA, for transport over an enterprise intranet). The Web service hides the implementation details of the service, allowing it to be used independently of the hardware or software platform on which it is implemented and also independently of the programming language in which it is written. This allows and encourages Web services-based application to be loosely-coupled, component-oriented, cross-technology implementations. Web services typically fulfill a specific task or a set of tasks. They can be used alone or with other Web services to carry out a complex aggregation or a business transaction. A client program connecting to a Web service reads the WSDL to determine what functions are available on the server.
With the advent of Web services, computing resources are exposed in an implementation neutral manner. Thus, for example, consider a reusable code component such as an enterprise Java bean or “EJB.” Typically, an EJB is protected with access control decisions on a method call. When exposed as a Web service, however, the EJB is defined by the Web service name, port and operation, where the operation typically represents a method. Because of the way in which a Web service is described (namely, through the WSDL), this “operation” may also correspond to the same functionality provided by a C-based resource, a CICS-based resource, or the like. This is another way of saying that a given functionality (whether implemented by an EJB, a C-based resource, a CICS-based resource, or the like) can be described with a single WSDL. The overall resource is described by the abstract WSDL, and then each particular implementation is described by a concrete binding of that WSDL.
It is known to allow for the application of access control policies (such as access control lists, or ACLs) to a given resource at the level of a WSDL, meaning that the same access control policies are applied to the resource, regardless of its back end implementation. Such policies are typically applied to the resource in the context of a virtual representation called a protected object space. A protected object space is a logical and hierarchical portrayal of resources belonging to a domain. The application of security policy at the level of a WSDL is consistent with a “best practice” approach to access control, where an access control decision preferably is made as close to the “edge” as possible. This technique, however, does introduce the potential that an entity offering the Web service has the same authorization decision implemented in two places, namely, an operation level decision at the Web service entry, and a method level decision at an application level. This in turn introduces the possibility for two different access policies applied to the same resource, with one policy applied at the Web services/operation level, and another policy applied at the application/EJB level. As a consequence, and to avoid potential conflicts, access control policies currently must be manually tracked and managed by a security administrator.
Similar operating constraints exist throughout Web service environments in a non security-related context and, in particular, where a given transaction has multiple “touch” points at a set of resources (e.g., a Web server, a Web service, a Web application, an MQ Queue, or the like) and where each of those resources has a policy (e.g., an audit policy) that is configured and administered by different entities. As in the access control environment, the individual policies are manually tracked and managed, and they are often inconsistent.